1. Field of the Invention
The invention relates to software development programs. More specifically, the invention relates to software that is a hybrid between a software compiler and a software interpreter. Like a software compiler, the software that is the subject of the invention creates object code. Unlike conventional compilers (and similar to interpreters), the invention does not separate human-readable source code from machine-readable object code. Instead, with the invention, executable files are edited directly.
2. Description of Prior Art
Object Code, Assemblers, Interpreters, and Compilers.
Computer programs define a series of steps to be taken by a computer and are in the form of object code (or machine code). Machine code, however, is not easily readable by humans. Assemblers were developed to translate human-readable assembly language into machine-readable machine code, but assembly language does not provide a high enough level of abstraction to software developers. As such, higher-level programming languages were developed to bridge the gap between human-readable source code and machine-readable object code. High-level programming languages include interpreted languages and compiled languages. Interpreted languages are written in human-readable source code and are translated to object code at run-time by an interpreter. Interpreted languages include Lisp, Scheme, and so-called scripting languages such as JavaScript.™, VisualBasic.RTM, PERL, and the like. Compiled languages are written in human-readable source code and are translated into object code by a compiler. Compiled languages include block-structured languages such as PASCAL, C, and C++. Compared with interpretation, compilation provides an increase in the efficiency of program execution, because with an interpreter, the source code is translated to object code each time the program is run (i.e. at run time), whereas with a compiler the source code is compiled into object code once. On the other hand, source code control (i.e. keeping track of which version of source code produced which object code) is easier with interpretation, since the source code is always available at run time.
Source code control for compiled languages, however, can be quite challenging. For complex compiled programs, dozens or even hundreds of separate source code files are required to properly compile a single object code file. As a result, software developers have procedures for determining when a particular “version” of a program should be defined. Different versions of source code are defined for each major release (e.g. alpha, beta, v1.0, v2.0), interim/patch release (e.g. v1.1, v2.2), or bug fix release (e.g. v1.1.1, v2.2.1). If a user of a particular version of a program has a problem, the user has to be able to communicate to the software developer which particular version of the program has the problem, and the software developer has to be able to correlate the particular program with a set of source code files. If the software developer has not been diligent about defining and ensuring the integrity of each version of its program, problems can arise for both the software developer and the end users.
Source code control is especially important for customized software programs. Customized software programs, as opposed to off-the-shelf consumer software, are typically written by small software development firms or independent contractors. In some cases, customized software programs that are delivered to clients include both object code and source code. Frequently, clients prefer to edit the source code in order to customize it or integrate it into an existing computing environment. In such cases, it is easy for the client to develop source code control problems. If the developer is called to the client's facility to assist with debugging a customized software program, the developer and the client may likely have different versions of source code and object code, and neither would be able to easily determine where changes had been made. Furthermore, the client or the developer may not have legal copies of the required compiler. If the developer needs to perform two separate customizations at two separate client sites, he/she may need to install two separate copies of the required compiler. Compilers, however, are expensive, and installing a compiler on multiple computers typically violates the software license terms of the compiler vendor. In some cases, the software developer's only option may be to try to decompile the object code into source code. The problem with decompiling software, however, is that the software developer's comments in the source code will not be recreated by the decompilation process. Formatting such as indenting, which makes source code easier to read for humans, is also lost by decompiling. Another option is for the software developer to use a resource editor to edit certain components of the customized software program. Resource editors, however, are not suitable when anything other than a cosmetic change is required.
Furthermore, as programs became more complex, programming languages became more complex, and numerous software design strategies emerged. For example, when compilation times increased, techniques were developed to make compilation faster and more efficient. Integrated development environments for object-oriented languages (such as Smalltalk.™, Objective-O, C++ and Java.™) offer developers the ability to build and design complex component-based programs in a given programming language. Component-based frameworks and protocols (such as ActiveX/COM.RTM, JavaBeans.™, and CORBA) provide standard rules and interfaces for regulating the interaction of heterogeneous components. “Visual” authoring tools (such as Sun Microsystem's.RTM Javastudio.™ and Symantec's.RTM Visual Cafe) provide graphic user-interfaces for creating and configuring component-based programs in a given object-oriented language. Script-oriented authoring tools (such as Apple's.RTM Hypertalk or Macromedia's.R™ Director.RTM) provide environments for developing multimedia programs using the tools' built-in functionality and single-purpose, proprietary scripting languages.
Unfortunately, these strategies frequently result in added complexity for the software developer, in general, and for customized software developers, in particular. Many customized software programs required only a small subset of the functions that are available to software developers today.